最終產出正確，仍可能漏掉「覆寫前先取得同意」這種要求；要確認它有沒有被遵守，還需要授權內容與執行順序的紀錄。

優惠碼功能的 ticket 裡，需求方列了 7 條驗收條件，也就是 AC。需求釐清 agent 會整理 Goal、Scope in、Scope out，再標出 AC 的問題；判定程式 scorer 目前比對的，就是這四個區塊。

但 agent 還有一個名為 replace_acceptance_criteria 的工具，用途是覆寫需求方的 AC 原文。整理後的內容是否正確，和原文能不能由 agent 自行修改，需要分別確認。

評分欄位相同，授權情況可以不同

先設想兩種流程，這不是實際執行紀錄。第一種先提出 AC 的修改內容，取得需求方同意後才覆寫；第二種直接覆寫。假設最後的 AC 和整理後的四個區塊都相同，兩種流程符合的要求仍有差別。

第一種有修改前的確認，第二種沒有。如果只把整理後的四個區塊交給 scorer，比對 goal state，兩次就會得到相同的判定，因為輸入根本沒有包含授權紀錄。

這不代表兩張卡的所有資料都一樣。卡上的留言、確認的內容與時間，都可能不同。repo 的 actualFields 只取 Goal、Scope in、Scope out、AC 標註來評分，不能從這些欄位的通過，推論修改已經得到同意。

即使系統保留舊版本，可以把 AC 改回去，也不表示事前確認可以省略。其他人可能已依改過的條件開始工作，恢復文字不一定能撤回後續影響。

寄對信箱，也可能少了一次確認

電話 agent 也有類似的要求，對方口頭提供 email 後，agent 要先複誦，等對方確認地址正確，再繼續處理邀請。這是在寄送之前增加一次核對的機會。

假設兩次都聽對 email，一次取得確認才寄送，另一次直接寄送，只檢查邀請是否寄到正確信箱，兩次都會通過：

要檢查這條規定，得回到通話紀錄，確認 agent 複誦了哪個地址、對方是否確認，以及寄送發生在確認之後。只找到一句複誦的話還不夠，先寄出、事後才確認，也不符合原本的要求。

把確認紀錄存成欄位，確實能讓程式檢查；但那個欄位仍要有可核對的依據。agent 自己寫下「已確認」，無法代替對方的回覆。

要檢查哪些步驟，不能只看它叫不叫流程

先確認再寄送是一種順序要求，先搜尋程式碼再讀文件也是。但兩者省略之後的影響不同，不能只因為都寫在 prompt 裡，就用同一套方式驗收。

以整理 ticket 為例，若 agent 先讀文件、再搜尋程式碼，最後整理出的內容仍符合需求，光是順序不同還不足以判定失敗。要求複誦 email，則得說清楚保護的是寄送前的地址確認，還是連複誦的措辭都必須固定。

因此，寫一條關於過程的檢查之前，要先回答三個具體問題：

• 限制的是哪個動作？ 例如覆寫需求方的 AC，或向某個地址寄送邀請。
• 動作之前必須具備什麼條件？ 是需求方同意這份修改，還是對方確認這個 email 正確。
• 用什麼紀錄判定條件成立？ 要能對上確認的內容與先後順序，只比工具名稱有沒有出現並不夠。

把這些條件寫清楚後，才有依據選擇檢查方式。直接拿整串工具呼叫去比對，可能同時限制了與這條規定無關的操作順序。

程式現在擋了什麼

需求釐清 agent 已有一個安全閘（safety gate），負責在覆寫 AC 之前攔截呼叫。這版 checkGate 的規則表只列了 replace_acceptance_criteria：

const NEEDS_CONSENT: Record<string, { gate: string; reason: string }> = {
  replace_acceptance_criteria: {
    gate: 'human-consent-before-overwriting-ac',
    reason:
      '拒絕：覆寫需求方寫的 AC 是不可逆的動作，需要人確認之後才能執行。請改用 post_comment 說明你想改什麼。',
  },
};

/** Null means the call may proceed. A block is a record, not just a refusal string. */
export function checkGate(call: ToolCall, now: Date = new Date()): GateBlock | null {
  const rule = NEEDS_CONSENT[call.name];
  if (!rule) return null;
  return {
    gate: rule.gate,
    tool: call.name,
    args: call.args,
    reason: rule.reason,
    at: now.toISOString(),
  };
}

這段程式只按工具名查表，遇到覆寫就回傳攔截紀錄，由呼叫它的程式中止這次工具執行。雖然名稱寫著 NEEDS_CONSENT，它沒有讀取人類同意的資料，也沒有同意後放行的分支。

因此，這個版本做得到的是阻止覆寫；前面假設的「確認後才改」流程，還需要確認紀錄與後續執行的設計。攔下一次工具呼叫，也不表示 ticket 已整理完成，產出的內容仍要另外驗收。

總結

整理後的卡片、邀請的收件人，都可以比對最終狀態；覆寫或寄送前是否取得確認，則需要額外的紀錄。只看目前 scorer 使用的欄位，會漏掉後一種要求。

要納入過程檢查，先寫清楚受限制的動作、必要條件與判定依據。現有 gate 已能阻止覆寫，但完整的同意後執行流程仍未建立，也還需要決定其他流程要求各該用什麼方式驗收。